Hm, this seems like an odd fix - if we expect that one of these directories is a subset of the other, I would expect us to not have two directories but instead annotate files with the compiletest revision support or a new dedicated feature to this effect. The current check just checks for same file name in both directories, which seems quite error prone - either file can get edited easily.

I think either we should move to revisions or a similar style feature. But I'm not sure the premise of this is quite right. If the code to validate attributes is in rustc's attribute validation, then rustdoc simply must run that - I don't think in that case we need to duplicate this for all tests. We don't rerun regular UI tests with rustdoc to make sure it's not using a different rustc parser or something; this seems like a similar case.

Yes, it's not great as is. For context: for a long time, rustdoc hid most attributes checks, preventing the warnings from rustc to be deniable in rustdoc. The idea was then to ensure this behaviour doesn't happen again.

Yes, it's not great as is. For context: for a long time, rustdoc hid most attributes checks, preventing the warnings from rustc to be deniable in rustdoc. The idea was then to ensure this behaviour doesn't happen again.

This can happen anyway though: because of #73566, the lints aren't ever emitted in the first place. This misleads people working on rustdoc because they could think it's a bug on their end that the lint shows up in rustc and not rustdoc, when in fact that's intentional. The tests only pass now because we happen to only test lints that run in rustdoc.

I think it makes sense for T-rustdoc to decide whether/how this check should look.

Like I said above, I don't think we should add this check.

Closing then.